Open
Conversation
Author
|
昨日のSymfonyWorldで私と同様のアプローチの方がいて感動しました! ただしこの方の場合UseCaseレイヤーはないです。 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
どのようにコーディングしましたか?
Controller→UseCase→Service→Model というレイヤーにしています。
Modelは、いつかSymfonyもDoctrineも捨てるかもしれないときにも移植できる部分として作ります。実際に他のパッケージ(社内packagist向けのプライベートパッケージ)として作ることも多いです。
ServiceまではDoctrineを知っても良いことにしています。
このコーディングのポイントを教えてください。
ビジネスロジックをDoctrine, Symfonyと疎結合に書くこと。
※ ただしこのシステムぐらいDB保存以外に何もしないシステムなら疎結合にする必要はないと判断するかも
どのようなことに注意していますか?
ビジネスロジックをDoctrine, Symfonyのクラス(レイヤー)に依存させないこと。
その他、コメントがあれば
現実の業務ではもう少しレイヤー分けを妥協することが多いです。
ModelがDoctrineに依存するのを許したり、UseCase→Service,Service→Serviceの依存時にinterfaceを挟まなかったり。
逆に言えばレイヤー分け以外の部分は基本的に妥協しません。
このクラス分けをビジネス側に許容させるために意識してコーディングスピードを激上げていると言っても過言ではありません。「中身がゴチャゴチャでもいいから動くものを速く作って」とは言わせません。